Working Group meeting
Date: 12/04/2022
Participants: Cecile Guasch, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Diagram explanation for Object Description design pattern: http://ontologydesignpatterns.org/wiki/Submissions:DescriptionAndSituation
-
Diagram explanation for AgentInRole - SocialReality design pattern:
-
the role of an agent also captures the description of that agent in a particular event
-
Discussion
-
How is the refactored version reflected in the owl model?
-
We should stick to the domain ontology and not include the upper level ontology layer. This should be used only to guide us into ePO modelling.
-
Descriptions appear at the moment; they are not phase specific. They can be updated in other phases.
-
Provide a temporal view of the procurement objects.
-
Consider renaming LotCompletionInformation since ePO does not provide any Completion class.
-
epo:Stipulation is the superclass that unifies all the term classes.
-
This might be a good class to keep in the core to have the epo:isSubjectToTerm predicate linked directly to it.
-
Rename it into epo:Term with the following definition: “A Governing condition or stipulation.”
-
-
Conceptualise the document as something that has an AccessURL.
-
For example, a Tender has all the data and also can have an AccessURL where the document can be downloaded.
-
The epo:Document is under epo:InformationRealization which is the file.
-
Is the perspective to describe the document or to describe the object of the document?
Decisions:
-
Agreeing to keep separate the ePO core elements from the notice elements.
-
Getting the model refactored within the next two weeks, including ePO conceptual model UML, OWL model and SHACL shapes and restrictions.
-
Publish on the TED documentation website where all the files can be found.
-
Deadline to provide the files in the github: 29th of April
-
Send email to the ontology working group with the link to the documentation on the TED website.
-
Next meeting should be on the 10th of May, in order to provide a week for review within the working group.
-
Mention in the documentation all the alignments to DUL and the context organised notice content (to be delivered after this deadline).
Working Group meeting
Date: 05/04/2022
Participants: Cecile Guasch, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Show WG how the Diagrams Values are currently transposed from the sandbox into the ePO model:
-
Show the Information classes
-
Show the AwardResult situation
-
Show completion values
-
-
In eForms (Rethink Tender/TenderLot, Tender as something englobing a group of lots)
-
Tender is perLot or group of lot, which is not necessarily the same as a LotGroup;
-
A contract is per Tender
-
-
Show proposed Review model.
-
We can look into Roles.
-
(Situations shall still be revised first)
Discussion
Roles overview
Proposed model is to use Role as a class that is played by an Agent.
We have three types of Roles:
-
Procurement role is directly involved in the procurement process;
-
Procurement subrole is secondary to the procurement process;
-
Related role is not involved in the procurement process.
Proposed renaming epo:Role in epo:AgentInRole:
Discussing an instance diagram example for a submission phase:
We just need to have the situation where organisation is already implied for the role of Tenderer.
In this case we will have all the URIs of the Organisation + all the URIs for roles + all the URIs for the submission.
Working Group meeting
Date: 22/03/2022
Participants: Cecile Guasch, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Show WG how the Diagrams Values are currently transposed from the sandbox into the ePO model:
-
Show the Information classes
-
Show the AwardResult situation
-
-
In eForms (Rethink Tender/TenderLot, Tender as something englobing a group of lots)
-
Tender is perLot or group of lot, which is not necessarily the same as a LotGroup;
-
A contract is per Tender
-
-
We can look into Roles
-
(Situations shall still be revised first)
Discussion
Tender and Values
-
There are multiple types of values:
-
Award related values
-
Submission related values
-
Estimated related values
-
-
The BTs should not be mentioned in the ePO definitions. Proposing to remove these in another place. Maybe as notes in the diagrams.
-
The value-type document should be saved somewhere in the github.
Diagram for estimation related values:
Diagram for submission related values:
-
A tender is usually composed of documents, one of them being a financial offer. The document that is the financial offer contains the financial offer value.
-
Should we remove the source of the epo:hasFinancialOffer relation from epo:Tender to epo:FinancialOffer?
-
When modelling the ESPD response we will need the epo:FinancialOffer class.
-
The goal is to make sure that ePO covers at best the eForms and standard Forms.
-
The ESPD should be a module itself and eOffer as well.
-
Moving epo:TechnicalOffer and epo:FinancialOffer to eOffer module.
-
Moving epo:ESPDResponse and epo:ESPDRequest to ESPD module.
-
The StatisticalInformation classes should remain in the ePO module.
Diagram for award related values:
The LotAwardDecision is the Result.
In the end, the value is associated with the Lot.
An Award Decision can not have a value.
Working Group meeting
Date: 15/03/2022
Participants: Cecile Guasch, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Continue discussing current issues and old decisions related to Amount and related classes.
-
Continue discussing the List of values:
-
BT-161
-
BT-118
-
BT-156
-
BT-709
-
BT-660
-
BT-710
-
BT-711
-
-
*Decide LotGroup model: *final version of Lot/LotGroup/SubmissionTerm/Tender
-
Tender is always submitted on a Lot (never on a LotGroup)
-
Tender may be subject to grouping by a LotGroup (at most one)
-
-
Consider SubmissionResult situation
-
Consider AwardResult situation
-
framework agreement is not interchangeable with award results even if some values may be the same.
-
-
What is the proper way to assign __phase dependent information to Lot_ / TenderLot and other Rigid (OntoClean meaning) classes? This brings us back to the value assignments as estimates, awardings. This relates to a large extent to the idea of situations and the reason they were evoked in the first place._
-
-
Discuss Roles and Situations.
Discussion
Decide LotGroup model
(proposed model)
This proposed model is in agreement with the WG members.
Below we have an example of grouping Lots:
SubmissionResult situation
Creating an instance example for tender submission:
Should we represent parallel ranking or keep it at the level of Lot?
It is decided to keep T B G 1&2 outside of the model.
Business terms that indicate values
BT-161 and BT-118 are just computed data.
StatisticalInformation is only good after the contract has been awarded.
Discussion about epo:StatisticalInformation:
-
Replace TenderLot with Tender in all attributes: check epo:StatisticalInformation.
-
We need epo:StatisticalInformation at the Result Notice level and Lot level.
-
This information is published only in Result, DAP and Completion Notices.
DECISIONS:
-
LotGroup is defined in ProcedureTerm.
-
Tender is always submitted on a Lot (never on a LotGroup)
-
Tender may be subject to grouping by a LotGroup (at most one)
-
/!\ This means that we still need to think about how to represent the financial offer for a LotGroup in the context of a LotGroup Tender submission.
Working Group meeting
Date: 08/03/2022
Participants: Cecile Guasch, Giorgia Lodi, Natalie Muric
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Continue discussing current issues and old decisions related to Amount and related classes.
-
Continue discussing the List of values.
-
What is the proper way to assign phase dependent information to Lot / TenderLot and other Rigid (OntoClean meaning) classes? This brings us back to the value assignments as estimates, awardings. This relates to a large extent to the idea of situations and the reason they were evoked in the first place.
-
Discussion
Business terms that indicate values
-
What is the proper way to assign phase dependent information to Lot / TenderLot and other Rigid (OntoClean meaning) classes? This brings us back to the value assignments as estimates, awardings.
-
Renamed the relationship in BT-27 from epo:hasInitialEstimatedValue to the already existing one in the model, epo:hasEstimatedValue. This is because the predicate is attached to the Lot/Procedure it implies that it is the initial value and no temporal reference is necessary.
-
Rename epo:hasTotalFrameworkValue to epo:hasTotalFrameworkAgreementValue
-
All relationships to epo:MonetaryValue that contains the word “Framework” should be renamed so that we add “Agreement” as well.
-
Rename relationship for eForms BT-156, Group Framework Value, to epo:hasFrameworkAgreementValue.
-
Presenting the example for the lot award decision situation:
-
Proposing to have a ProcedureObject as a superclass for Lot and LotGroup:
-
We need to connect the LotGroup with some Term classes in the ePO model.
-
Presenting a new example of Tender Submission:
-
Presenting an example of the awarding:
Working Group meeting
Date: 01/03/2022
Participants: Cecile Guasch, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Continue discussing current issues and old decisions related to Amount and related classes.
-
Tender was merged into TenderLot:
-
show the result
-
ask about “isSubjectTo” submission term
-
-
Continue discussing the List of values: https://docs.google.com/spreadsheets/d/1siAHrX4ueK5GexJ0N3zMg4oHA4ygYlW0d96ainJw9bQ/edit?usp=sharing
-
What is the proper way to assign phase dependent information to Lot / TenderLot and other Rigid (OntoClean meaning) classes? This brings us back to the value assignments as estimates, awardings. This relates to a large extent to the idea of situations and the reason they were evoked in the first place.
-
-
Discuss Documents diagram.
Discussion
Tender & TenderLot merging
-
There were two isSubjectTo relations:
-
epo:Tender epo:isSubjectTo epo:SubmissionTerm
-
epo:TenderDocument epo:isSubjectTo epo:SubmissionTerm
-
-
These two seem redundant after merging Tender with TenderLot.
-
The attributes from the SubmissionTerm class are mixed between Tender and Submission related attributes.
-
The guarantee and the electronic Signature are not at the Submission level.
-
We might need to create a TenderTerms class.
-
The bi-directional epo:attaches/epo:isAttachedIn relation between Tender and TenderDocument does not seem right as well.
-
A document may attach another document.
-
Removed any epo:attaches/epo:isAttachedIn relations from subclasses of epo:Document and create an unidirectional relation epo:attaches/epo:isAttachedTo at the epo:Document level.
-
Changing the definition for epo:Document with the following:
-
epo:RequestForClarification is on the EO side, but has nothing to do with the Tender (not a Tender Document).
This is a diagram for a future Application Profile:
-
The RequestForClarification, RequestForParticipation and ExpressionOfInterest are not generalisations of TenderDocument.
-
TenderDocument is no longer needed.
-
The association attaches / isAttachedTo should be replace by associatedWith.
-
The attaches predicate between Tender and ESPD response, Technical Offer and Financial Offer should be subproperties of associatedWith within any AP that will be created.
*Decisions: *
-
Investigate whether we need to create a TenderTerms class. (to distinguish between the action of submission and the content of submission)
Working Group meeting
Date: 22/02/2022
Participants: Cecile Guasch, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Continue discussing current issues and old decisions related to Amount and related classes.
-
What is the proper way to represent Lots & LotGroup and Tender/TenderLot & TenderLot group? Continue modelling the Tender/TenderLot example in the sandbox.
-
In deciding the above how do awarding, selection and exclusion criteria interplay in the case of Lots and LotGroups. This is important to understand how the TenderLots (and eventually TenderLotGroups) relate to the Lots.
-
What is the proper way to assign phase dependent information to Lot / TenderLot and other Rigid (OntoClean meaning) classes? This brings us back to the value assignments as estimates, awardings. This relates to a large extent to the idea of situations and the reason they were evoked in the first place.
-
List of values: https://docs.google.com/spreadsheets/d/1siAHrX4ueK5GexJ0N3zMg4oHA4ygYlW0d96ainJw9bQ/edit?usp=sharing
-
Discussion
Lot and LotGroup
-
When (In which situations) LotGroup is relevant and when it is not?
-
Is the TenderLot relevant for competition/submission/evaluation only and it disappears in the contracts?
-
-
Does the LotGroup have its own award criteria or reuses those of the composing lots?
-
Is the LotGroup a subclass of Lot? They seem to share lots of attributes in common, and for this reason a common super-class would come in handy for good modelling. For example both of them may have FrameworkAgreementTerms, various criteria, estimatedValues, etc.
-
Then the same applies to TenderLotGroup, if such a class is necessary at all?
Page 11 of F2F-WGM 9th (from 14 of June 2019)
-
It was noted that the award criteria are not dependent upon a group of lots because the award criteria are applied before grouping the lots.
-
The Working Group had troubles understanding the Directive and the eForms concerning the Group of Lots value. It looks like the market could do synergies combining groups of lots but still the award criteria are set for the individual lots. An issue could be raised to eForms once the WG has clarified its findings especially concerning BG 330 Group award which seems to be in contradiction with recital 79 of Directive 2014/24/EU. It was also noted that the ontology covers scenarios that may not exist in all Member States.
Consequence for the model (?):
-
LotGroup is merely a grouping of lots, without many attributes of its own, or …
-
LotGroup is (almost) like a Lot, which overrides the properties of composing lots. For example, Lot "estimated values" will be overridden by the LotGroup values.
-
SelectionCriteria of a LotGroup can override (take precedence on the sum of the two) the SelectionCriteria of individual Lots or keep the SelectionCriteria of the individualLots.
-
LotGroup is a collection, it is not another type of Lot. It is a mechanism to group lots and differentiate selection criteria.
TenderLot and TenderLotGroup
-
What is the connection between TenderLots to Lots and Groups? Is there a better way of calling the TenderLot?
Current definitions:
-
TenderLot: Part of the tender that applies to the related lot. Additional Information: See also the definitions for Tender and Lot for a complete understanding. (apparently no longer needed)
-
Tender: Information submitted by the economic operator to specify its offer regarding one or more lots or the whole procedure, in response to the call for tender. (WG approval 07/11/2018)
-
The common part that is submitted, in the case of multiple submissions by the same tenderer, is moved elsewhere (i.e. ESPD response, which has to be submitted anyway each time including the exclusion ground) and therefore we no longer need this generalisation. Thus we can merge the Tender and TenderLot classes.
-
Decision: Investigate if/how we can delete the TenderLot class?
Decision: no need for TenderLotGroup.
Business terms that indicate values
-
List of values: https://docs.google.com/spreadsheets/d/1siAHrX4ueK5GexJ0N3zMg4oHA4ygYlW0d96ainJw9bQ/edit?usp=sharing
-
What is the proper way to assign phase dependent information to Lot / TenderLot and other Rigid (OntoClean meaning) classes? This brings us back to the value assignments as estimates, awardings
Additional notes:
Presenting the instance example for tender with selection criterion.
With the new ESPD they have to reuse the same exclusion criteria for each TenderLot.
Exclusion Grounds are at the level of Procedure.
The financial and technical Award Criteria are to be set at the level of each Lot.
LotGroup can have the same kind of characteristics as Lots. The cardinalities are different.
One Lot has just one offer per each Selection Criteria.
A LotGroup can have its own Selection Criteria that overrides the SelectionCriteria for each of the Lots or keep the ones from each Lot.
AwardCriteria will be the same for LotGroup as the ones for each Lot.
We will need to go for a different granularity for ESPD in the case of FinancialOffer.
Award Criteria are actually questions.
The Financial Offer is per Lot.
Presenting a real world example of a tender at instance level.
Delivery example diagram
Competition diagram:
epo:hasEstimatedValue should be the same in all procurement phases.
-
Corrigendum: The estimated value might change only if a corrigendum notice is instantiated.
-
Should we accept to extend the definition of an object previously announced? (for example Lot) It’s a good practice that once an object is instantiated they should not be modified, but only referred to. (ex: Lot hasEstimatedValue and Lot hasAwardedValue; awarded value should not be a property of a lot but of something else)
Decision: Put all the BGs in the value type spreadsheet.
Working Group meeting
Date: 15/02/2022
Participants: Cecile Guasch, Giorgia Lodi, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Natalie Muric
Approved implemented changes
-
Rename epo:Value class to epo:MonetaryValue class.
-
Maximum and Minimum attributes were proposed to be used as predicates: epo:hasMinimumAmount and epo:hasMaximumAmount; and epo:hasOverallAmount.
-
Delete epo:Amount class and use epo:MonetaryValue class instead which has amount number and currency attributes.
-
The source of the relations epo:hasEstimatedUserConcessionRevenue and epo:hasEstimatedBuyerConcessionRevenue have been moved from epo:Lot to epo:TenderLot. This is in accordance with eForms Regulation (BT-160 and BT-162).
-
Attributes from epo:StatisticalInformation, epo:hasLowestReceivedTenderLotValues and epo:hasHighestReceivedTenderLotValues, become relations to epo:MonetaryValue. (BT-710 & BT-711)
-
Contract class has no value(s). This is in line with the eForms regulations. Note: It is the ContractTerm and Framework Agreement Term classes that may have specified monetary values. (BG-310 does not require value) Note: The contracts have values in some datasets (to be investigated which ones and to be decided at a later stage: e.g. tender lot awarded value becomes the contract awarded value).
-
Subcontract class is deleted because current forms and eForms do not require it.
Old model:
New model:
Discussion
Introduction of discussions last June on Monetary value and previous discussions on subcontract
Presenting how the sandbox implements Monetary value.
It is agreed with the WG the RevenueConcession concepts are transformed into predicates
Statistical information is looked at and the plurals are to be made into singular.
It is agreed to have a predicate hasHighestReceivedTenderlotValue from StatisiticalInformation to MonetaryValue (the same for LowestReceived….)
This was agreed as the Tender is specifically mentioned in the Notice.
It seems that Contract is not specifically mentioned in the eForms. It should be checked with DG GROW if this is because it can be implied from the TenderValue.
Discussion whether the aggregate of contract values in the notice should be considered in the ontology
It should be noted that the consumption of the Contract will need to be shown in future versions of the ontology.
In Italy:
HasEstimatedValue is in planning
HasMaximumValue is in the tendering
HasAwardedValue is in Awarding
Has MaximumEstimatedValue in Contract (not sure if correct)
This shows we should pay attention to situations, without meaning that process modelling is needed.
This is represented in the SubcontractingEstimate class that the WG accepts along with the removal of the subcontract class that can be reintroduced if a use case is provided at a later stage.
It is noted furthermore that the subcontract is not mentioned in the contract (though this should be confirmed by other MS).
Working Group meeting
Date: 08/02/2022
Participants: Cecile Guasch, Hilde Kjølset, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Discussion
-
We started grouping all classes from the ePO model, like in the image below:
-
Provide a narrative for all the packages in order to make it more understandable by the business people.
-
Short discussion regarding the documents diagram which was also discussed last time.
-
Kept only the top level of notices in the model: planning, competition, DAP, result, completion and contract modification.
-
Predicates epo:relatesToNotice and epo:relatedToNotice are from the 2.0.1 version:
-
Why not include them at the class level?
-
epo:refersToResultNotice is a specific type of the predicate epo:relatesToNotice? This can be deleted because this relation exists at the level of an epo:Notice class. But this has a different cardinality (mandatory 1) so we can keep it and use it for an AP of notices.
-
-
-
Discussion about the structure of phases in the Procurement domain.
-
Is it valuable to have a Result Notice or just a Contract Award Notice?
-
Mentioning that a Result Notice contains CAN general, CAN social and also design.
-
It is good to have this classification.
-
-
Showing the situation usage example for Winner BG:
-
If we decide that we don’t want to keep the Notice subclasses in the model, we should find a way to move the attributes from some of them.
-
Prepare a list with all the problems that we found while doing the mappings of the content to eForms notices. (publish a future agenda; maybe as a GH issue, with priority if possible.)
Working Group meeting
Date: 01/02/2022
Participants: Cecile Guasch, Hilde Kjølset, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Update HTML version of model-refactoring branch with new diagrams of documents and present them to the WGM.
Discussion
-
Do we have abstract classes or not? Because abstract classes are not instantiated, it is ok to have them since they won’t generate new URIs. Do we really need all these classes for the requirements (standard forms)?
-
Requirement:
-
It should cover eForms, and current forms if possible
-
It should cover notices, eOrdering and eCatalogue.
-
-
Nothing regarding the payment or submission in the data. Only regarding the result of these actions.
-
A request for providing some more information regarding the new proposed model was made.
-
Besides eForms and standard forms, there is some BDTI data from the Italian and Norwegian side.
-
We concentrate on stabilising this for eForms and Notices and then challenge the model to include some use cases that are not there.
-
There are some use cases where the roles are not defined that well.
-
We should find a small set of data that fit most of the use cases.
-
We don’t know yet if every info from the current forms can be mapped to eForms.
Notice core module
-
epo:hasLegalBasis is for the Procedure or for the Notice?
-
It is the content of the document that matters, so the Procedure should have a legal basis.
-
If we have this at the PRocedure level we could assure a robust approach.
-
There is an exception if we have only a PIN and not a Procedure, so we will talk about a project.
-
The fact that notice types belong to a legal basis is something that is part of the internal system that has to choose the notice type.
-
It is good to analyse which notice type is needed where but it is not needed to express the public procurement information.
-
Presenting the eForms mappings.
-
The mappings to the Notice content should not be part of the ePO. We are doing this low-level exercise to discover if the current model can express everything.
Questions:
-
If we have a project and it changes the legal basis in between what can we do?
-
What happens to fields that are not mandatory based on the country?
-
We should provide the best cardinalities in order to avoid this.
-
Documents hierarchy
-
It appears that the way Notices are currently defined are not directly mappable to the eForms or Standard Forms.
-
We advise to revise the level of granularity at which these concepts are defined.
-
For example, in eForms and Standard forms there are two types of ContractAwardNotice whereas in EPO only one.
-
More notice types are missing.
Discussion on PIN subclasses:
-
In the NoticeType PIN the acronym is used with two meanings:
-
Prior Information Notice
-
Periodic Indicative Notice
-
-
We shall be careful when each is used and modelled accordingly in Ontology.
-
In notice-type controlled vocabulary, the BuyerProfile is considered a PIN:
Discussion on CallForCompetition class:
-
In the current model this is a procurement document, but in notices it is a notice type.
-
epo:CompetitionNotice class is an epo:ProcurementDocument as well, and not epo:ClassForCompetition. === Questions:
-
Should epo:Notice be a subclass of epo:ProcurementDocument?
-
From the directive:
-
Call for competition is a procurement document.
-
Shouldn’t BuyerProfile be a subclass of PIN?
Working Group meeting
Date: 25/01/2022
Participants: Cecile Guasch, Giorgia Lodi, HK, Natalie Muric
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Present HTML version of model-refactoring branch and present Buyer role and Agents diagrams. Role dependencies included.
Discussion
On branch feature/model-refactoring we have a common model for both models.
The HTML format is on docs.ted.europa.eu[docs.ted.europa.eu]
In the eProcurement Ontology section we have the Working Group meetings. We provide the meeting minutes in two formats: one long text or meeting by meeting.
In the epo-docs section we have two versions of the documentation: dev and 2.0.0.
In the dev version we have the HTML reports based on models existing in various active branches.
We could create a 2.0.1 version and add the HTML report for the feature/frozen-2.0.1 branch.
The epo:Purpose class could be included in the procurement objects.
We will make sure to add diagrams that reflect the model properly.
Buyer Role diagram
The Procurement Service Provider Role can act on behalf of the Buyer. Both roles can be played by a Central Purchasing Body.
Central Purchasing Body should be a type of Role and not an Organisation.
epo:actsOnBehalfOf and epo:delegatesAncillaryActivitiesTo relations are now at the Role level, and not at the Organisation level like in the 2.0.1 version.
Based on the definition of the buyer role, the Buyer is a conflation of both Awarder and Acquirer.
By being so specific with the roles, we may add complexity to the model.
Checking the Open Contracting Data Standard: https://standard.open-contracting.org/1.1/en/schema/codelists/#party-role
If we specify just the Central Purchasing Body, it should be enough to cover all data.
Discussion based on the eForms codelists:
https://op.europa.eu/en/publication-detail/-/publication/73a78487-cc8b-11ea-adf7-01aa75ed71a1
Discuss the BuyerProfile class. It has only an attribute, epo:hasURL. We could add this attribute in the epo:Buyer class in order to simplify the model. We need to further discuss this issue in order to clarify.
Working Group meeting
Date: 18/01/2022
Participants: Cecile Guasch, Hilde Kjølset, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
A new branch from sept 2021 was created to host a frozen version of the ePO model at that time, including Reg2015 and BDTI AP modules. The later APs are removed from the dev version of ePO (master branch).
-
Present the DEV version of the ePO documentation.
-
Some epo:Indicator attributes are missing. We recommend adding the indicators where possible.
-
Document on explaining modelling roles
-
Finished implementing Subroles
-
Discuss indicator attributes:
-
The use case for BT - 634 Procurement Relaunched is the announcement that a Procedure should be relaunched.
-
An option is to add it to the Contract Award Notice phase.
-
Can we use epo:announcesToBeRelaunched instead of this?
-
This is related to epo:hasNonAwardJustification .
-
A procedure can be cancelled before Awarding.
-
-
New definition for epo:hasAdditionalNonAwardJustification attribute on epo:LotAwardDecisionSituation class:
“Further justification for the non award.
Additional Information:
This is generally used when the non award reason code is set to “Other”.
WG 18/01/2022”
-
The procurement process is per Lot.
-
epo:announcesProcedureWillBeRelaunched relations were added from epo:ContractAwardNotice to epo:Procedure and epo:Lot in order to map BT-634.
-
At the Procedure level we created a relation epo:isProcedureToBeRelaunched attribute as epo:Indicator on the epo:ContractAwardNotice class.
-
At the Lot level we created a relation epo:announcesCancelledLotToBeRelaunched between epo:ContractAwardNotice and epo:Lot.
-
Added a new definition for epo:isProcedureToBeRelaunched: “Indicates whether a whole procedure or only a part of it shall be relaunched.
Additional Information:
If it’s True it means either the Procedure or Lot shall be relaunched.
This indicator should be used in tandem with the relation announcesCancelledLotToBeRelaunched if it concerns one or more lots.
If, however, no link to the lots is specified, then it indicates that the whole procedure shall be relaunched.
WG approval 18/01/2022”
Composition & specification relations between Procedure and Lot
-
We recommend using composition type of relation between Procedure and Lot and delete specification relations.
-
Changed epo:isComposedOf to epo:hasComponent.
-
Procedure does not exist without Lots.
Inclusion relation between Tender and TenderLot
-
A Tender does not exist without TenderLots.
-
Changed the inclusion relation between Tender and TenderLots to a composition. === Subroles implementation
The subroles were initially modelled as relations from Buyer and Reviewer role classes to Lot class. All these relations have been reified into either Terms or Situations, i.e. deleted and the appropriate relational class created or augmented.
Working Group meeting
Date: 11/01/2022
Participants: Cecile Guasch, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugen Costetchi
Note editor: Andreea Pasăre
Agenda:
-
Extension management methodology (for CEN needed soon)
-
Need for having notices published in RDF format in Cellar
-
Discussion regarding at-voc:nuts and other options that can be used instead
-
Document on explaining modelling roles
-
Core Location alignment - go through the open issues labelled Location and close where possible
-
GitHub structure presentation - branches & documents
Extension management methodology
-
In CEN working will be discussed process models, needing to refer to the EPO.
-
Extension of EPO (as APs or models) with specific attributes and relations is foreseen.
-
Potential issue: redundant extension; therefore EPO governance is needed.
-
Need: asset governance formalisation for EPO.
-
Guidance document needed before Q2.
Core location implementation
Agents diagram:
-
epo:Location has been removed
-
epo:Address has been changed to locn:Address (with specific attributes and definitions)
-
All predicates from epo classes to epo:Location were moved to locn:Address and renamed to epo:hasAddress and epo:hasRegisteredAddress
Competition diagram:
-
Replaced epo:LocationCoordinate with dct:Location (with specific attributes and definitions)
-
Added locn:Geometry class (with specific attributes and definitions)
Discussion:
-
epo:hasLocationCoordinate should be deleted
-
locn:Address should be linked to locn:Geometry
-
Should we move epo:hasOpeningPlace to dct:Location? Double check if epo:OpeningTerm is a spatial object
-
It seems that epo:Location class was not removed; it should be removed
-
In eForms we use L3 NUTS code, but if we align to core location they provide locn:adminUnitL1 and locn:adminUnitL2
-
Should we consider INSPIRE instead of Core Location or ask Core Location to make changes in order to be more flexible
-
Should locn:adminUnitL1 link to at-voc:country instead of at-voc:nuts?
-
What can we do with locn:adminUnitL2? Keep it linked to at-voc:nuts.
-
We miss level 3 of at-voc:nuts. We could add a predicate for L3.
-
Ask Core Location for details on how we can go to L3 NUTS.
-
Change the model to the following diagram and test it with real data.
GitHub structure - branches & documents:
-
Renamed branches to better reflect the development:
-
feature/sandbox-roles
-
feature/notice-systematisation
-
feature/model-refactoring
-
-
Generated HTML reports for master branch and model-refactoring branch; added them to epo-docs repository in order to be displayed on https://docs.ted.europa.eu/
-
Created automated owl generation when publishing on master, along with a conformance check.
Discussion:
-
Delete the sandbox folder from master branch.